Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-123.txt

Text File | 1994-12-08 | 43.9 KB | 1,168 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 23 Jun 92       Volume 1 : Issue 123

Today's Topics:

    q: marching ants as vbl task problems
    GetGWorldPixMap
    Wanna Keep Up with the Future: Mac Hacker needs unix book rec
    Zortech C++ wins award?
    Info on Toolserver?
    Do people actually use ViewEdit 3?
    The Device Thing...
    Print/Save Graph @ 300dpi - how?
    Debugging in MacApp


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Andre "A Mac Plumber" Srinivasan)
Subject: q: marching ants as vbl task problems
Date: 20 May 92 14:42:10 GMT
Organization: Computer Science Dept., University of Pittsburgh

i wrote a simple vbl task based on the marquee code from dts.  the
idea was to create a standalone routine that would need little work
from the person using it.  it works very nicely, except for the
following:

1) when a pulldown menu overlaps the ants, the ants just march right
over the menu.  it looks like i will have to remove the task when a
mouse down occurs and then install it again afterward.

2) nothing selected from the apple menu works while my application is
in the foreground.  when it is suspended, all of these selections that
i made are launched.

3) when i switch to the finder and then return to my app, the ants
don't march very fast at all; they crawl very slowly.  if i switch to
some other app and then return, i don't have this problem.

i guess i'm also asking if i should just do this as a null event task
rather than mucking with interrupts (which turned out to be easier
than i thought if you ignore my troubles above).

thanks for your thoughts.

                            -andre.


- --
Andre Srinivasan  :
734 LRDC          :         This Space For Rent
U. of Pittsburgh  :
[e-mail] :

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 21 May 92 15:37:16 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Andre "A Mac Plumber" Srinivasan) writes:
> 1) when a pulldown menu overlaps the ants, the ants just march right
> over the menu.  it looks like i will have to remove the task when a
> mouse down occurs and then install it again afterward.

You might try patching MenuSelect() to determine this window.

> 2) nothing selected from the apple menu works while my application is
> in the foreground.  when it is suspended, all of these selections that
> i made are launched.

Are you calling the standard eventloop stuff? Are you using "OpenDeskAcc()"
when you get the Apple menu picks?

> 3) when i switch to the finder and then return to my app, the ants
> don't march very fast at all; they crawl very slowly.  if i switch to
> some other app and then return, i don't have this problem.

WOW!

> i guess i'm also asking if i should just do this as a null event task
> rather than mucking with interrupts (which turned out to be easier
> than i thought if you ignore my troubles above).

VBLs are cool, in that they do not get blocked. NULL events would probably
prove to be more trouble-free in the long run, however.

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Ed Watkeys)
Date: 21 May 92 21:28:41 GMT
Organization: Distant Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Tim Endres) writes:
> > 2) nothing selected from the apple menu works while my application is
> > in the foreground.  when it is suspended, all of these selections that
> > i made are launched.
>
> Are you calling the standard eventloop stuff? Are you using "OpenDeskAcc()"
> when you get the Apple menu picks?
>
I had this problem in something I was writing, and I traced it back to the
fact that I was ignoring update events. Everything worked fine except Apple
Menu selections.

Ed

- --
Ed Watkeys, Sys Admin.  "...The errors of great men are more venerable
Distant Software         because they are more fruitful than the truths
[e-mail]     of little men..."  -- Friedrich Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 21 May 92 20:37:29 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Andre "A Mac Plumber"
Srinivasan) writes:
>
> i wrote a simple vbl task based on the marquee code from dts.  the
> idea was to create a standalone routine that would need little work
> from the person using it.  it works very nicely, except for the
> following:
>
> [ problems deleted]
>
> i guess i'm also asking if i should just do this as a null event task
> rather than mucking with interrupts (which turned out to be easier
> than i thought if you ignore my troubles above).

Ignoring the problems you have already listed, there is a VERY GOOD reason why
you should not do marching ants at interrupt time. FrameRect (I assume you are
calling FrameRect) has the potential of moving blocks in the heap. Moving blocks
at interrupt time is one of the things you absolutely must not do. First of all,
there is the potential of invalidating any dereferenced handles your application
may have. Second, you'd could be re-entering the Memory Manager, something it
was not designed to do. This could lead to a corrupt heap and crashes.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 22 May 92 03:01:42 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Andre "A Mac Plumber" Srinivasan) writes:
>
> i wrote a simple vbl task based on the marquee code from dts.  the
> idea was to create a standalone routine that would need little work
> from the person using it.  it works very nicely, except for the
> following:
>
> 1) when a pulldown menu overlaps the ants, the ants just march right
> over the menu.  it looks like i will have to remove the task when a
> mouse down occurs and then install it again afterward.
>
> 2) nothing selected from the apple menu works while my application is
> in the foreground.  when it is suspended, all of these selections that
> i made are launched.
>
> 3) when i switch to the finder and then return to my app, the ants
> don't march very fast at all; they crawl very slowly.  if i switch to
> some other app and then return, i don't have this problem.
>
> i guess i'm also asking if i should just do this as a null event task
> rather than mucking with interrupts (which turned out to be easier
> than i thought if you ignore my troubles above).

You cannot call QuickDraw at interrupt level, such as a VBL task.
You'll need to draw during null events or when _WaitNextEvent returns
false.  Also, while you're trying to get background time or nullEvents
you'll need to pass a sleep value to WaitNextEvent that provides you
with enough polling time.  Typically this should be 60 ticks, or once
a second.  Many applications will pass a longer time or even MAXLONGINT
to WaitNextEvent because they do not need any nullEvents.



- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

---------------------------

From: [e-mail] (Michael Peirce)
Subject: GetGWorldPixMap
Date: 21 May 92 18:29:37 GMT
Organization: Peirce Software

I have a question about using GetGWorldPixMap().  In Inside Mac VI
it says to never access the portPixMap of an offscreen GWorld (for
using in things like LockPixels()).

I ran across some code (QuickTime sample code) that says something about
GetGWorldPixMap() not always working.  My code currently does the
access itself and hasn't run into problems, but I'd like to DO THE
RIGHT THING.  But I also don't want to run into problems if GetGWorldPixMap()
messes up sometimes.

Does anyone know the real answer to this?

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --  Makers of...        --   San Jose, California USA 95117
- --                      --   voice: [phone] fax: [phone]
- --     SMOOTHIE         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Date: 22 May 92 03:58:29 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Michael Peirce) writes:
>I ran across some code (QuickTime sample code) that says something about
>GetGWorldPixMap() not always working.  My code currently does the
>access itself and hasn't run into problems, but I'd like to DO THE
>RIGHT THING.  But I also don't want to run into problems if GetGWorldPixMap()
>messes up sometimes.
>Does anyone know the real answer to this?

Yup, I do (hey, it bit me). In 32-bit QuickDraw 1.2, GetGWorldPixMap
does not return the portPixMap field of the gworld, but rather returns
the portVersion field (a word) in the high word and the high word of
the portPixMap field in the low word. It does:
    move.l    (a0),8(a7)
(a0 containing the gworldptr and 8(a7) being where the return value of
the pascal function should be placed) instead of:
    move.l    2(a0),8(a7)
which does the right thing.

This is fixed in 32-bit QuickDraw 1.3 (the System 7 version). Although
one of the suggested workarounds is to grab it yourself from the
CGrafPort record, I play it a little safer and grab it myself only if
I'm running on 32-bit QD 1.2 or lesser, and otherwise I use
GetGWorldPixMap.

Hope this helps

- -Ivanski

- ---
Ivan Cavero Belaunde ([e-mail])
DiVA Corporation

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 22 May 92 05:48:47 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
>I ran across some code (QuickTime sample code) that says something about
>GetGWorldPixMap() not always working.  My code currently does the
>access itself and hasn't run into problems, but I'd like to DO THE
>RIGHT THING.  But I also don't want to run into problems if GetGWorldPixMap()
>messes up sometimes.

Under System 7, use GetGWorldPixMap; under System 6, access the
field directly.   This is covered in the Q&A Stack and in Dev Tech
Answers on AppleLink; I'll paste the appropriate entries below.

Grobbins           [e-mail]

Usual disclaimers apply.
- ---------------------------------------------------------------

from Dev Tech Answers on AppleLink:

Testing for GWorld availability

How do I tell if GWorld calls such as NewGWorld are available? Is the
existence of 32-Bit Color QuickDraw the only condition?
___

Presence of 32-Bit QuickDraw is a sufficient but not a necessary condition
for GWorld support. Under System 7, GWorld routines and certain other color
calls are allowed on 68000-based Macintosh models, even though Color
QuickDraw is not available. However, special precautions must be taken to
use GWorlds in a compatible way.

On a Macintosh without Color QuickDraw running System 7.0, the GWorld
created by NewGWorld uses an extended GrafPort, not a CGrafPort. NewGWorld
will return an error if asked to create a GWorld with depth greater than 1
unless Color QuickDraw is available.

The PixMap field of a GWorld should not be accessed directly; instead, use
the function GetGWorldPixMap. Similarly, to obtain the address of the PixMap
data, use GetPixBaseAddr rather than access the baseAddr field of the
PixMap. These routines are documented in the Graphics Devices chapter of
Inside Macintosh Volume VI. One-bit GWorlds are also discussed in the article,
"QuickDraw's CopyBits Procedure: Better Than Ever in System 7.0," from issue 6
of develop.

Unfortunately, GetGWorldPixMap does not work properly under 32-Bit QuickDraw
1.2, so use theGWorldPtr^.portPixMap instead if and only if Gestalt reports
the QuickDraw version as greater than or equal to gestalt32BitQD and less
than gestalt32BitQD13.

The proper test for the availability GWorlds is

retCode1 = Gestalt(gestaltQuickdrawVersion, &qdVersResponse);
retCode2 = Gestalt(gestaltSystemVersion, &sysVersResponse);
if ((retCode1 == noErr) &&
    (retCode2 == noErr) &&
    ((qdVersResponse >= gestalt32BitQD) ||
     (sysVersResponse >= 0x0700))) {
    /* do GWorld stuff */
}

This is also the appropriate test for other "color" routines available on
all Macintosh models under System 7: RGBForeColor, RGBBackColor,
GetForeColor, GetBackColor, and QDError. (QDError returns zero if Color
QuickDraw is not present.)

Alternatively, if color or greyscale GWorlds are required, check bit
gestaltHasDeepGWorlds (bit 1) of the response to selector
gestaltQuickdrawFeatures. It is set if GWorlds with true CGrafPorts are
available. Incidentally, the gestaltHasColor bit for
gestaltQuickdrawFeatures erroneously returns true for black-and-white
machines under System 7.0.



Copyright Apple Computer, Inc.  1985-1991



GetGWorldPixMap bug and workaround

Why does GetGWorldPixMap (when called on a Macintosh II, IIcx, or IIx running
system software version 6.0.5 or 6.0.7 with 32-Bit QuickDraw 1.2) return a
combination of the device field (two bytes) and the first two bytes of the
portPixMap field? Is this a bug?
___

Your analysis of GetGWorldPixMap is exactly right: It doesn't work correctly
in system software version 6.0.5 and 6.0.7 with 32-Bit QuickDraw 1.2. It
returns a value that's two bytes before the value it's supposed to return.

The solution is to use GWorldPtr->portPixMap instead of GetGWorldPixMap. It's
safe to do this, but you should use GetGWorldPixMap under System 7. Not only
is the bug fixed there, but dereferencing the port is dangerous under System 7
because it may not be CGrafPort. Use Gestalt with the gestaltQuickdrawVersion
selector to determine whether you can use GetGWorldPixMap. If Gestalt returns
a value from gestalt8BitQD ($0100) through gestalt32BitQD12 ($0220), then
GetGWorldPixMap either doesn't exist or is the buggy version. If it returns
gestalt32BitQD13 ($0230) or higher, then GetGWorldPixMap does exist and works
correctly. Interestingly, GetGWorldPixMap can be called on a black-and-white
QuickDraw machine under System 7. It returns a handle to a structure which
should be treated as a BitMap structure, though there are some undocumented
fields after the normal BitMap fields. To tell whether GetGWorldPixMap is
available on a black-and-white QuickDraw machine, you must check the system
software version by calling Gestalt with the gestaltSystemVersion selector. If
it returns $0700 or higher, GetGWorldPixMap is available.



Copyright Apple Computer,  Inc.  1985-1991



---------------------------

From: [e-mail] (opcode ranger)
Subject: Wanna Keep Up with the Future: Mac Hacker needs unix book rec
Date: 18 May 92 22:01:08 GMT

I'm a Mac programmer, and haven't had much use for Unix, but I can read the
writing on the wall.I'm keen to keep up on the future of the Mac and Apple
post-Mac computing.  From what I've gathered, the future lies in Unix, and/or
an OS which bears some passing resemblance to some form of Unix.  I don't know
what Taligent will be like, but I would presume that some knowledge of Unix
would be helpful (AIX keeps popping into my head; was Taligent supposed to use
that as an OS?).

Anyway, although I've used -- minimally -- Unix systems, I don't know much
about them. I'd like to get a book that would give me a good __programmer's__
introduction to  Unix.  That is, I'm not really interested in how to awk, grep,
cat, etc.  I'm more interested in how Unix works.  I'd also like to book that's
on the bleeding edge; that is, I'd like prefer a book that is relevant to me as
a Mac/GUI programmer, i.e. where Unix is heading, not where it was 10 years
ago.  I'd also like a book that gets me pretty advanced pretty quickly and is
not just a puffy tutorial.

One book that caught my interest to some extent which gives considerable info
on Unix (including Mach) is "Modern Operating Systems" by Tanenbaum (1992).
Since I'm also keen on learning something about OS's in general, it seemed
interesting. Anyone have any opinions on this book (it is pretty new, I know).

Replies by e-mail would be much appreciated, since my phone link to this
newssite is rather expensive.


Thanks!

Robert

- --
==============================================================================
= [e-mail] * "Out there on a darkened road, the lights =
= are dead and the cars explode" -- "Good Things", Sisters of Mercy           =
==============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 19 May 92 18:03:45 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] (opcode ranger) writes:
> I'm a Mac programmer, and haven't had much use for Unix, but I can read the
> writing on the wall.I'm keen to keep up on the future of the Mac and Apple
> post-Mac computing.  From what I've gathered, the future lies in Unix, and/or
> an OS which bears some passing resemblance to some form of Unix.  I don't know
> what Taligent will be like, but I would presume that some knowledge of Unix
> would be helpful (AIX keeps popping into my head; was Taligent supposed to use
> that as an OS?).

Funny, I do know of many former UNIX programmers - including me - that have
switched over to MacOS or Windows programming mostly due to the lack of
a market for commercial UNIX office products...

Most of the modern kernels have ideas taken/stolen from UNIX or Mach, so
yes it makes sense to check these out. Then again in many cases application
developers don't need to know everything about the kernel implementation,
threads/semaphores, memory management and networking are the usual
things 'good-to-know', but for instance figuring out how MMU mapping works,
or how the scheduler spins around is only good for real kernel hacking
(and in some cases dev. driver work).

> One book that caught my interest to some extent which gives considerable info
> on Unix (including Mach) is "Modern Operating Systems" by Tanenbaum (1992).
> Since I'm also keen on learning something about OS's in general, it seemed
> interesting. Anyone have any opinions on this book (it is pretty new, I know).

The Tanenbaum book is a nice overview of operating system concepts. If you
want to check out the SysV or BSD internals there are many books available
in a decent bookstore (like the BSD UNIX Operating System by Leffler, McKusick,
Karels and Quarterman - but that's a kernel level book).

Most of my UNIX books are back home nowadays so I can't give a nice listing,
if I remember correctly you are really looking for an API level programming
book, and there should be many of those out on the market today.

Cheers,
Kent


+++++++++++++++++++++++++++

From: [e-mail] (Larry Meyer - mac weenie)
Date: 22 May 92 01:24:19 GMT
Organization: Xinet, Berkeley

This is an interesting issue, but i think this guys confused
kernel with GUI. As I understand it, taligent will be an
object oriented os (whatever that is). this really has nothing to
do with unix; the only currently shipping parallel that I can think of
is the O-O GUI built into the NeXT.

Obviously, the mac os has big problems.
It takes much too long to build apps and there's no support for
multi-processing and other such "real-os" features which are built into unix.
I assume, though, that Apple is not going to solve the latter by putting
a very nice o-o interface builder on top of unix, a-la the NeXT. So if your
worried about obsolet mac skills, I wouldn't worry about learning
about the unix kernel (unless you enjoy low-level hacking).

if you really want to learn unix, start with Kernighan and Pike's book
(it's called something like "A introduction to the Unix programming
environment".) Then move on to one of the many Addison Wesley books
which deal with kernel implementation (I personnaly like the "red daemon"
book, by Karels et al., and which is called something like "The design
and implementation of 4.3 BSD").

if you want to learn what taligent will be like, you ain't going to
find that info in any book.

I personally think that the NeXT's less ambitious approach
makes sense; does anyone out there have any idea what an
object oriented operating system is? If so, please tell me!

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Date: 22 May 92 22:10:26 GMT
Organization: Oceania Health Care Systems

In article <[e-mail]> [e-mail] (Larry Meyer -
mac weenie) writes:
> does anyone out there have any idea what an
> object oriented operating system is? If so, please tell me!

Check out Go Corp's PenPoint (and give yourself plenty of time, by the way).  A
good book to peruse is "The Power of PenPoint" by Robert Carr and Dan Shafer
(not really worth buying in my opinion - your mileage may vary).

- -Steve

- --
    Steve Dakin                      Oceania Health Care Systems
 [e-mail] (NeXT mail)       Palo Alto, CA [phone]
 [e-mail]                  "That one deserves a ... WOW!"

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 22 May 92 19:22:18 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Larry Meyer -
mac weenie) writes:
> if you want to learn what taligent will be like, you ain't going to
> find that info in any book.

If you want to know about object oriented kernel design, check out issues
of the OOPSLA and Usenix C++ conference proceedings. The Usenix
"Computing Systems" magazine contains also a lot of really
good articles about kernel design, especially concerning object oriented
kernels. You need to join Usenix though to get this one.
- --
                                              Cheers, Kent


---------------------------

From: [e-mail] (Terry Thiel)
Subject: Zortech C++ wins award?
Date: 20 May 92 00:36:46 GMT
Organization: University of Illinois at Urbana

The June Byte magazine says Zortech C++ (now owned by Symantec) won their
readers choice award for best Mac programming language.  Is this based on
the Xortech implementation or Symantecs?  I was under the impression that
Symantec was not producing this package.
- -Terry

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 20 May 92 04:36:18 GMT
Organization: Kalamazoo College

[e-mail] (Terry Thiel) writes:
>The June Byte magazine says Zortech C++ (now owned by Symantec) won their
>readers choice award for best Mac programming language.

Why do I get the feeling that this says more about Byte's readers
than it does about Zortech...?
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Civil Rights:  1964 - 1992.  R.I.P.

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: Wed, 20 May 92 06:46:52 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

>The June Byte magazine says Zortech C++ (now owned by Symantec) won their
>readers choice award for best Mac programming language.

       That's incredible.  I'd like to hear from some happy users.
For that matter, ANY active users of the Mac product.

       Zortech C++ is also available for Intel CPUs, under DOS, Windows,
and OS/2, and that product is much more solid than the Mac product.
Could Byte have mixed up the reports on the other platforms with the
Mac product?

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Tim McClarren)
Date: 20 May 92 19:27:08 GMT
Organization: University of Illinois at Urbana

John Nagle writes
> >The June Byte magazine says Zortech C++ (now owned by Symantec) won
their
> >readers choice award for best Mac programming language.
>
>        That's incredible.  I'd like to hear from some happy users.
> For that matter, ANY active users of the Mac product.
>
>        Zortech C++ is also available for Intel CPUs, under DOS, Windows,
> and OS/2, and that product is much more solid than the Mac product.
> Could Byte have mixed up the reports on the other platforms with the
> Mac product?
>
>                     John Nagle

Byte is a worthless piece of trash.  They also claim in the May issue
that OS/2 is the first threaded OS.  I'd suggest if you want to know
anything about the industry, avoid Byte.  See comp.sys.next.advocacy
or misc for recent threads about Byte's ongoing stupidity.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 20 May 92 21:00:57 GMT
Organization: Kalamazoo College

[e-mail] writes:
>
>Byte is a worthless piece of trash.
>I'd suggest if you want to know
>anything about the industry, avoid Byte.

My favorite boner is "The Mac has its own built-in speech hardware and
software...  The Mac comes from the factory with a built-in
text-to-speech program called MacInTalk [sic], which drives the
built-in speech hardware..."  (April 1992, p. 167)
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "When I read the 486 manual, I was amazed that they had got all this
  working.  Then I got to the bug list in the back, and said, "Oh.
  They _didn't_ get it all working."  - Mitch Bradley

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 20 May 92 19:35:05 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (John Nagle) writes:
> >The June Byte magazine says Zortech C++ (now owned by Symantec) won their
> >readers choice award for best Mac programming language.
>
>        That's incredible.  I'd like to hear from some happy users.
> For that matter, ANY active users of the Mac product.
>
>        Zortech C++ is also available for Intel CPUs, under DOS, Windows,
> and OS/2, and that product is much more solid than the Mac product.
> Could Byte have mixed up the reports on the other platforms with the
> Mac product?

I'm also amazed... It seems they had a mixup with the compiler, maybe
they assumed that the customers on the Mac side are as happy as those in the
DOS world.

Fortunately my Byte subscription ended two months ago, and I don't think
I will renew it :-).

Cheers,
Kent
PS: Private comments

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Date: 21 May 92 20:03:46 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <[e-mail]> [e-mail] (Terry Thiel) writes:
>The June Byte magazine says Zortech C++ (now owned by Symantec) won their
>readers choice award for best Mac programming language.  Is this based on
>the Xortech implementation or Symantecs?  I was under the impression that
>Symantec was not producing this package.
>-Terry
>

The last version of Zortech C++ I reviewed did not support large
model (in the MPW linker).  This makes it useless.  I can't
imagine why anyone who would say that this is "best" for anything.

If this is fixed, it may have some uses.  For example, it will be
faster than MPW C++ (not saying much).  It will probably produce
better code than MPW C++.

It will still have numerous parsing bugs for C and C++.  It will
still have the most outrageous treatment of the "pascal" keyword
I've seen to date.

Think C+Objects will still be a superior environment.  It will be
a faster compiler, it will produce better code, the debugger will
be better, we will have been using it for more years.

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ernest J Hill)
Organization: Massachusetts Institute of Technology
Date: Thu, 21 May 1992 21:41:33 GMT

I of course don't know for sure, but I think this Byte report is just an
isolated error.  As far as general coverage industry magazines for the
technically minded, I don't think anything comes CLOSE to Byte.  If you want to
know who's buying what, read InfoWeak. If you want to know what a bunch of
coneheads thinks about the latest release of Envelope Licker Professional, you
can read MacWeak or MacLoser.  If, on the other hand, you're interested in
hardware explained on a reasonably technical level, the algorithms behind real
software, and a unique historical perspective, read Byte.

Just One man's opinion.
- --Foss


+++++++++++++++++++++++++++

From: [e-mail] (Levent Mollamustafaoglu)
Date: 22 May 92 04:46:24 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] (Ernest J Hill) writes:
>I of course don't know for sure, but I think this Byte report is just an
>isolated error.  As far as general coverage industry magazines for the
>technically minded, I don't think anything comes CLOSE to Byte.  If you want to
>know who's buying what, read InfoWeak. If you want to know what a bunch of
>coneheads thinks about the latest release of Envelope Licker Professional, you
>can read MacWeak or MacLoser.  If, on the other hand, you're interested in
>hardware explained on a reasonably technical level, the algorithms behind real
>software, and a unique historical perspective, read Byte.
>

You are right, in a sense... When I worked in the industry and wrote
software for the PC's (yecccch..) I followed Byte enthusiastically.
Certainly its technical articles are superb, they are sometimes
machine-independent and they go into the details of a particular
technology or algorithm. MacWorld, MacUser etc. are very light, in
comparison to Byte. But I think they are too PC-specific in coverage.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 22 May 1992 15:32:26 GMT

You guys are comparing Apples to PCs (and Oranges)...MacUser and MacWeek
(and MacWorld) are NOT written for programmers. Simple. Byte is much more
technical. MacTutor is for programmers. Don't try to complain about a
magazine when it has nothing to do with what you are comparing it to.

- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm   CI$: 70712,515
- -- communications.networks.cool tunes...

---------------------------

From: [e-mail] (OOI)
Subject: Info on Toolserver?
Date: 20 May 92 18:23:13 GMT
Organization: Computer Science Dept, QMW, University of London


Appreciate if anyone who has used this, do mail me on what it is
and what can it do.

I believe it is a Distributed server like environment running on
top of the mpwshell allowing tools to respond via Apple Events.
Am I correct?


Thanks for all replies.



+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 21 May 92 20:37:37 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (OOI)
writes:
> Appreciate if anyone who has used this, do mail me on what it is
> and what can it do.
>
> I believe it is a Distributed server like environment running on
> top of the mpwshell allowing tools to respond via Apple Events.
> Am I correct?

   The ETO distribution has a whole document about the Toolserver, but
what you stated is in principle correct. It does *not* run on top
of any shells, it's actually a micro-shell, running in the background,
processing AEs that correspond to a published protocol, triggering
tools to be executed.

   If anyone who is *seriously* thinking about supporting the Toolserver with
tools would like to get the specs, send me an email ([e-mail]).

   Actually this document should be published on ftp.apple.com and AppleLink
as reference material, so it's now noted in my DayMaker Todo list :-).
- --
                                              Cheers, Kent


---------------------------

From: [e-mail] (Dan King)
Subject: Do people actually use ViewEdit 3?
Date: 20 May 1992 11:56:42 -0700
Organization: University of Southern California, Los Angeles, CA


Howdy, y'all.  I'm frustrated and thought I'd see if there was a less painful
way to build views for MacApp 3 than using ViewEdit (3.0b2).  It seems like
every time I boot the damn thing I end up with a hung machine and a bus error.

Do people actually use this thing?  Have you all gone back to 2.0 views?  Is
there a newer (more stable) version around?

Frustrated,
dank


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 21 May 92 20:34:54 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Dan King) writes:
>
>
> Howdy, y'all.  I'm frustrated and thought I'd see if there was a less painful
> way to build views for MacApp 3 than using ViewEdit (3.0b2).  It seems like
> every time I boot the damn thing I end up with a hung machine and a bus error.
>
> Do people actually use this thing?  Have you all gone back to 2.0 views?  Is
> there a newer (more stable) version around?

   It's a well-known secret that ViewEdit 3.0b2-b3 were buggy, the latest one,
b4, should have cured some of the problems.

   But if you still don't trust ViewEdit 3.0, here's what to do:

a) Use ViewEdit 1.0.1 or IcePick and convert resources to 'View' format
using ViewPromoter.

b) Use text resource definitions, I do that mostly because I got used
to those su***rs.

c) Bribe someone to send you an alpha copy of Ad Lib, a future tool shown
at the latest Bamada meeting, a really nice 3.0 Views creation tool.

d) Continue complaining to MACAPP.TEST about problems, and hopefully the
last bugs in ViewEdit 3.0 are shaken out before final release.

Over-out.
- --
                                              Cheers, Kent


---------------------------

From: [e-mail] (Jim Ryan)
Subject: The Device Thing...
Organization: Adobe Systems Incorporated
Date: Thu, 21 May 1992 04:57:28 GMT

OK, I'm confused (nothing new), I think... :)

I would like to center my app's window, and I would like it to work
on everything from a Mac Plus' single B&W screen to a Mac II (or whatever)
with 5 color monitors.  Should I:

A        Use screenbits.bounds
B        Use GetMainDevice
C        Use GetCurDevice
D        All of the above
E        None of the above
F        Some of the above
G        Above the above

Let's say my app has one main window.  I want it centered at launch.  Then,
as the user play with it, and decides to move it to another monitor, I
would like my "Center Window" command (a menu item) to center my
app's main window in whatever monitor it currently happens to reside.  Also,
I'm centering alerts (1/3) and dialogs, and would like them to appear in the
same window as my apps main window.

What variable to I use???  Is there a way to know for sure if there is
more than one monitor in use?

Do I call GetMainDevice to center the main window at launch, and then
GetCurDevice thereafter?  Does it work with non-ColorQD Macs?
Am I lost?  IM is a bit vague on these issues,
or if I'm not looking in the right place, please point me in the right
direction.

Thanks,
jr

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Thu, 21 May 1992 19:18:46 GMT

In article <[e-mail]> [e-mail] (Jim Ryan) writes:
>I would like to center my app's window, and I would like it to work
>on everything from a Mac Plus' single B&W screen to a Mac II (or whatever)
>with 5 color monitors.  Should I:
>
>A        Use screenbits.bounds
>B        Use GetMainDevice
>C        Use GetCurDevice
>D        All of the above
>E        None of the above
>F        Some of the above
>G        Above the above

And the answer is:  F!

>Let's say my app has one main window.  I want it centered at launch.  Then,
>as the user play with it, and decides to move it to another monitor, I
>would like my "Center Window" command (a menu item) to center my
>app's main window in whatever monitor it currently happens to reside.  Also,
>I'm centering alerts (1/3) and dialogs, and would like them to appear in the
>same window as my apps main window.

You want to center things on the device which is showing the largest part of
your window.

>What variable to I use???  Is there a way to know for sure if there is
>more than one monitor in use?

Yes.  _GetDeviceList returns a handle to the beginning of the linked list of
graphics devices.  If there is more then one item in this list that is an
active screen device, then you have multiple monitors.

>Do I call GetMainDevice to center the main window at launch, and then
>GetCurDevice thereafter?  Does it work with non-ColorQD Macs?

_GetCurDevice won't help you figure out where the window is.  Graphics
devices don't exist on non-Color Macs.

On non-Color Macs the answer to your question is easy: just use
screenBits.bounds.  On color Macs it's more involved.

Here's some code:

 FUNCTION GetMajorDevice (box: rect): GDHandle;
  VAR
   md, gd: GDHandle;
   sect: rect;
   area, maxArea: longint;
   temp: boolean;
 BEGIN
  md := nil;
  maxArea := 0;
  gd := GetDeviceList;
  WHILE gd <> nil DO
   BEGIN
    temp := SectRect(gd^^.gdRect, box, sect);
    WITH sect DO
     area := (right - left) * (bottom - top);
    IF area > maxArea THEN
     BEGIN
      md := gd;
      maxArea := area;
     END;
    gd := GetNextDevice(gd);
   END; { WHILE gd <> NIL DO }
  IF md = nil THEN
   md := GetMainDevice;
  GetMajorDevice := md;
 END; { FUNCTION GetMajorDevice }


What this does is return a handle to the device that contains the majority
of the area of a given rectangle.  This rect should be in global
coordinates.  To use this to figure out which monitor a window is on, you
pass it the windows portRect (converted to global coordinates).  There is
a problem with this code in that it doesn't check that a given device is
actually a screen device.  It should be calling _TestDeviceAttribute(gd,
screenDevice), and possibly _TestDeviceAttribute(gd,screenActive), although
I don't know how likely it would be to encounter an inactive screen device in
the device list.   Once you get a handle to the major device, simply center
your window within gd^^.gdRect.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

---------------------------

From: [e-mail] (WILLETT,THOMAS CARTER)
Subject: Print/Save Graph @ 300dpi - how?
Date: 14 May 92 16:18:22 GMT
Organization: Georgia Institute of Technology

I have written my own application that does some data processing, and I plot
graphs, save them as pict files, and print them.  However, I only know how
to do it at 72dpi, and I have more than enough data that 300dpi would give me
a much better plot.  What are the mechanics of utilizing the 300dpi resolution
of the printer when drawing my graphs with Quickdraw?
thanks.

- --
thomas willett
Georgia Institute of Technology, Atlanta
[e-mail]
"Violence is the last refuge of the incompetent." - Salvor Hardin (Foundation)

+++++++++++++++++++++++++++

From: [e-mail] (Terry Weymouth)
Date: 20 May 92 14:28:31 GMT
Organization: University of Michigan Engineering, Ann Arbor


> [e-mail] (WILLETT,THOMAS CARTER):
> What are the mechanics of utilizing the 300dpi resolution

How about writing in Postscript? Anyone tried this?

---------------------------

From: [e-mail] (T.J. Fiske)
Subject: Debugging in MacApp
Organization: Qualcomm, Inc., San Diego, CA
Date: Thu, 14 May 1992 22:59:10 GMT

I am currently trying to develope an application under the MacApp
development shell.  In other languages you can output to the screen
for debugging purposes utilizing the cout << "ERROR:", but on the
macintosh I have not been able to do this.

Does any body have a good method for debugging MacAPP C++ code?

I could sure use the help, BOY could I use it!!

Thanks,

    -- T.J. Fiske


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 18 May 92 19:29:48 GMT
Organization: MacDTS Mongols

In article <tfiske.705884350@qualcom>, [e-mail] (T.J. Fiske)
writes:
>
> I am currently trying to develope an application under the MacApp
> development shell.  In other languages you can output to the screen
> for debugging purposes utilizing the cout << "ERROR:", but on the
> macintosh I have not been able to do this.
>
> Does any body have a good method for debugging MacAPP C++ code?
>
> I could sure use the help, BOY could I use it!!

MacApp 2.0, just compile with -Debug mode and you should get a transcript
view where cout works.

MacApp 3.0, we took out this transcript view, it's now part of SourceBug,
so if SourceBug is running in the background, and you do a cout (-Debug), a
transcript
view will automagically pop up. This also works with SADE. Also, the TTranscript
view class is part of the unsupported ones, so you could use it for whaever
doing a little bit hacking.

See, that was easy!

Cheers,
Kent
Dynamic Language Advocate

+++++++++++++++++++++++++++

From: [e-mail] (Mark Mullin)
Date: 21 May 92 06:02:18 GMT
Organization: Institute for Cliffgrazing DogBears

Since you feel that it was so easy to explain how to use Sourcebug,
have you any suggestions for those of us who don't want to use
sourcebug cause a 1 minute link then takes 10 minutes ?
MMM


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 21 May 92 23:57:28 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Mark Mullin) writes:
> Since you feel that it was so easy to explain how to use Sourcebug,
> have you any suggestions for those of us who don't want to use
> sourcebug cause a 1 minute link then takes 10 minutes ?

   Don't remember if I talked about SourceBug, but we are really talking
about .SYM file generation than about anything else. Yes, use MacsBug,
the symbolics generated with -mbg on is quite ok, and I use MacsBug
half of the time with my C++ code.

   As for 10 minutes, that's long, then again it depends on the machine,
setup, tricks and so on. See my TN 313 for suggestions how to decrease
the linking times (without turning off -sym on).
- --
                                              Cheers, Kent


---------------------------

End of C.S.M.P. Digest
**********************